Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Oracle Performance Tuning and Optimization
(Publisher: Macmillan Computer Publishing)
Author(s): Edward Whalen
ISBN: 067230886x
Publication Date: 04/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


Tuning

The office system is tuned almost identically to the OLTP system. The data access patterns that determine the tuning and design are similar in both systems. Carefully analyze these things to determine whether adjustment to these parameters is necessary:

  DB_BLOCK_BUFFERS Block buffers are probably the most critical area in the office system. Having an insufficient number of block buffers results in higher-than-normal I/O rates and possibly an I/O bottleneck.
  Library cache. Check The V$LIBRARYCACHE table, which contains statistics on how well you are using the library cache. You should be able to reduce the library cache misses by increasing the size of the shared pool.
  Open cursors. You may have to increase the number of cursors available for a session by increasing the Oracle parameter OPEN_CURSORS.
  Cursor space for time. If you have plenty of memory, you may be able to speed access to the shared SQL areas by setting the Oracle initialization parameter CURSOR_SPACE_FOR_TIME to TRUE.
  Spin counts. By tuning the Oracle initialization parameter SPIN_COUNT to enable spinning on resources (that is, the process spins instead of going to sleep while waiting for a resource to become available), you may see improved performance. SPIN_COUNT is useful when you have multiple CPUs and short-running transactions.
  Data dictionary cache. To check the efficiency of the data dictionary cache, look at the dynamic performance table V$ROWCACHE. If necessary, you may have to increase the shared pool size.
  Rollback contention. You can tell if you are seeing contention on rollback segments by looking at the dynamic performance table V$WAITSTAT. If the number is high, you need more rollback segments.
  Use many rollback segments. The rollback segments for an office system may have to be a little larger than the rollback segments traditionally used for OLTP.
  Latch contention. Latch contention can be determined by examining the dynamic performance table V$LATCH. If there is a large amount of contention, you may need to take action as described in Chapter 9, “Oracle Instance Tuning.”
  Checkpoints. If the checkpoint processes are too hard on the system, you may have to adjust the duration and effect of the checkpoint.
  Archiving. You may have to adjust the effect archiving has on your system by changing the speed of the archive process.

These are some of the areas you should pay particular attention to when tuning a system used primarily for the Oracle Office. The areas that require the most attention are I/O and memory because they are so closely related. By optimizing the use of memory, you can reduce I/Os (which are probably running near the limitations of the hardware).

Review of the Oracle Office System

This section compared the characteristics of the Oracle Office system with those of the OLTP system. Because the two systems are similar, the layout of the office system and its tuning parameters are very similar to those of the OLTP system. Although the other components of the office system use additional CPU resources, they do not adversely affect the performance of the system.

The Oracle Office system is to designed to provide office services such as messaging and scheduling. Oracle Office is a client/server application that uses the Oracle RDBMS system on the system servers. The Oracle Office system also uses a replication method to replicate data throughout the system.

If you are a user of the Oracle Office system, be sure to use the monitoring facility that comes with the Office package. It can help you find problem areas before they become critical.

WebServer Systems

The World Wide Web (WWW) encompasses a large amount of information, distributed in a common format among computer systems. This information is made up of documents, or Web pages. These Web pages are made up of text, images, and hypertext that links one Web page to another Web page.

In the few years since the WWW has been around, its popularity has grown at an amazing rate. It is very rare to see a large or medium sized company without its own business Web page. The World Wide Web is based on a set of open standards that allow all computer hardware and OS vendors—as well as Oracle—to participate in the Web.

It is only the Web’s presentation system that is standardized. Where and how you store your data is up to you. The Oracle WebServer product is an add-on to the Oracle RDBMS that assists in these tasks. Using Oracle WebServer, you can store the data in a database for quick and personalized retrieval.

The Oracle World Wide Web interface kit as well as the WebServer system can help you use the power of Oracle with the unlimited potential of the Web.

System Characteristics

In general, the Oracle WebServer system has some characteristics of both OLTP and TextServer systems. It also has some unique characteristics:

  Concurrent online users. These users perform different activities against the same database.
  Large amounts of text and image data. The amount of data depends on your particular installation, but the type of data is primarily text and graphics.
  Random data access. The transactions tend to cause significant amounts of random I/O on the system.
  Heavy network load. The system is design to serve users on the Internet. Depending on your traffic patterns, your network load can be quite high.

The data is accessed in a very random manner, as it is in an OLTP system. However, the WebServer access tends to be of a read-only nature. Currently, very few applications allow writing into a WWW site, but this is slowly changing.

Design and Tuning Hints

Because the Web system tends to have characteristics of both the OLTP and the TextServer system, the design of your system should take into account both characteristics. In designing a WebServer system, use the following goals to achieve optimal performance:

  Isolate sequential I/Os. Most of the time spent reading from or writing to the disk is spent seeking to where the data is located. If you can reduce seeks, you can achieve more I/Os per second.
  Spread out random I/Os. Random I/Os have a maximum rate per drive. By spreading the I/Os out across many drives, you increase the overall rate.
  Avoid paging and swapping. Any time the system pages or swaps, performance is severely degraded. Avoid this at all costs.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.